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(57) A method for providing validated electronic 
commerce transactions is disclosed. A transaction orde r 
g enerated by a purchaser has a unique transaction, 
identifier associated therewith and the purchase order 
is transmitted t o a merchan t and<ffjjen v fo a transaction 
administrator. The transaction administrator contacts 



the original purchaser and provides the generated 
unique transaction identifier to c onfirm whether or not 
the transaction order was initially provided by the pur- 
c hase r. Upon venncanon ot origination of the transaction 
order by the purchaser and other transaction informa- 
tion, the transaction administrator notifies the merchant 
and the transaction may be completed. 



65- 



Recipient 55 



Processor 75 



115 or 125 



CO 

CO 
CM 



LU 



Originator 50 \ 95 

| Processor 70 



List 100 



80--. 






Transaction 
Admin .60 




Processor 61 





FIG. 3 



Printed by Jouve, 75001 PARIS (FR) 



BNSDOCID: <EP 1026644A1 I > 



EP 1 026 644 A1 



Description 



[0001] The present invention related to electronic 
transaction, and more particularly, to a method and ap- 
paratus enabling validated electronic transactions be- s 
tween an originator, a recipient and a transaction admin- 
istrator. 

[0002] The increasing use of electronic media, such 
as the Internet, smart phones, screen phones and tele- 
vision with World Wide Web access, have expanded the 10 
opportunities for electronic commerce. In electronic 
transactions two or more entities electronically process 
specific tasks ranging from exchanging information, pur- 
chase and payment to real estate transactions. Finan- 
cial examples of electronic transactions include pur- is 
chase and payment transactions. Purchase transac- 
tions are performed using credit and debit cards. Pay- 
ment transactions are performed in paying bills, sending 
refunds on return merchandise, sending awards, etc. 
[0003] A common set-up for commercial (including 20 
electronic) transactions is illustrated in FIGURE 1. The 
transaction includes processing steps taking place be- 
tween three entities, namely, a client 10, a merchant 20 
and a payment authority (PA) 30. A delivery system be- 
tween the client 1 0, merchant 20 and a PA 30 exists so 25 
that the steps required for transactions can be per- 
formed properly. 

[0004] FIGURE 2 is a flow diagram generally illustrat- 
ing the steps involved in a commercial transaction. In 
step 1 2, the client 1 0 places a purchase order to the mer- 30 
chant 20. The purchase order will include the item(s) the 
client desires to purchase and payment information on 
an account from which to purchase the item. This pur- 
chase order may be for goods, services or any other 
item normally involved in commercial transactions. 35 
When a purchase order is received by the merchant 20, 
the merchant sends at step 13 a request for payment 
authorization to the payment authority (PA) 30. 
[0005] Inquiry step 1 4 determines whether or not the 
purchase is authorized at the PA 30. This step is per- 40 
formed by the processing equipment 35 associated with 
the PA 30. The PA 30 responds at step 15 with a confir- 
mation and authorization for the payment amount once 
the payment information regarding the client 10 checks 
out. If the payment information is not confirmed with the 45 
PA 30, the PA transmits a rejection at step 16 for the 
requested purchase authorization transaction. Upon 
confirmation of the transaction, the merchandise is de- 
livered to the client 10 at, step 17. Upon rejection of the 
transaction, the merchant 20 notifies the client 10 of the 50 
denial of authorization by CCA 30 at step 18. The se- 
quence of steps 12, 13, 14, 15, 16, 17 and 18 must occur 
within some type of traceable delivery system. 
[0006] The delivery system between the client 1 0 and 
the merchant 20 can be a regular mail system, tele- 55 
phone system, computer network or any other delivery 
system like UPS or Federal Express. The delivery sys- 
tem between the client 10 and the merchant 20 must 



also have some tracking capability. The delivery system 
between the merchant 20 and the CCA 30 is typically a 
private network providing Point-Of-Sale (POS) process- 
ing. All necessary information is transferred between 
two or more points in this network with a tracking mech- 
anism that can follow the transactions. All of the above 
steps can also be executed within electronic transac- 
tions. 

[0007] However, in electronic commerce it is not pos- 
sible to properly authenticate entities and transactions. 
In order to properly authenticate entities such as a client 
10 and the merchant 20 performing a transaction, there 
is proposed a standard SET (Secure Electronic Trans- 
actions) in which each entity obtains a Certificate of Au- 
thentication from a Certificate Authority (CA) whereby 
clients and merchants can authenticate each other be- 
fore performing any transaction by digitally signing the 
contents of the transaction and having the digital signa- 
ture authenticated by the CA : This open exchange of 
digital signatures increases the potential of fraud. Thus, 
there is also a need for secure electronic commerce 
where the exchange of digital signatures between enti- 
ties is eliminated. 

[0008] An unauthorized client can send in a purchase 
order with an address to which to deliver the goods and 
no proper tracking can be established to validate wheth- 
er or not an authorized client has initiated the purchase 
order. The PA 30 cannot establish whether the request 
from merchant 20 ,is initiated by the true client 10 or an 
unauthorized client. It is possible that a purchase order 
was never actually generated by an authorized client .10 
but by someone else at the merchant's place of busi- 
ness. Additionally, the amount of the authorization can 
be changed or inflated by the merchant 20 and thus be- 
come an invalid request. The PA 30 does not know the 
real amount requested by the authorized client 10 and 
does not have any mechanism to confirm this informa- 
tion. Finally, the delivery address could be different from 
the actual address of the client 10, and the true client 
would not receive the merchandise, just the bill. Further- 
more, there is no tracking system for automatically val- 
idating electronic transactions. Because of these is- 
sues, electronic transactions are a risky proposition. 
[0009] In today's electronic banking, payment trans- 
actions take place by sending payment requests to a 
bank or third party to create electronic checks. The bank 
then makes payment to the client's payee or third party 
then sends the electronic check to the client payee. 
However, since the client's name, bank A.B.A. number 
and account number are easily accessible, it is easy for 
an unknown third party to create fund transfers even 
though data can be exchanged securely between the 
client and the bank. Furthermore, electronic check 
processing still has to be carried out as shown in FIG- 
URE 12 where PA 30 is a Banking System. Electronic 
commerce on the Internet is still a risky business be- 
cause in the U.S. for example, the bank is liable for this 
kind of fraudulent transaction. There is therefor a need 
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to provide validated banking transactions over the Inter- 
net. 

[0010] According to a first aspect of the invention 
there is provided a method of validating an electronic 
transaction between an originator and a recipient com- 
prising the steps of: generating an electronic transac- 
tion, including a transaction identifier, at the originator; 
transmitting the transaction to the recipient; and com- 
municating information between the originator and the 
transaction administrator to validate the transaction 
based on the transaction identifier. 
[0011] The transaction may be transmitted from the 
recipient to the transaction administrator as part of a ver- 
ifying step. The verifying step may include transmitting 
the transaction identifier from the recipient to the trans- 
action administrator and authenticating the transaction 
identifier received by the recipient. The verifying step 
may include authenticating the transaction identifier re- 
ceived by the transaction administrator. 
[0012] The information may be communicated be- 
tween the originator and the transaction administrator 
after the transaction has been transmitted and a request 
for verification of the transaction may be transmitted 
from the transaction administrator to the originator. 
[0013] A verification of the original transaction trans- 
mission may be transmitted from originator to transac- 
tion administrator. 

[0014] The transaction identifier may be generated at 
the originator and transmitted from the transaction ad- 
ministrator to the originator as part of the verifying step, 
thereby enabling authentication of the transaction iden- 
tifier to be performed at the originator. 
[001 5] The entire transaction may be transmitted from 
the transaction administrator to the originator as part of 
the verifying step, to enable authentication of the trans- 
action to be performed at the originator. 
[0016] Alternatively information may be communicat- 
ed between the originator and the transaction adminis- 
trator before the transaction has been transmitted, in 
which case the transaction identifier may be generated 
at the transaction administrator and transmitted to the 
originator for inclusion in the transaction. The the trans- 
action identifier may then be authenticated at the trans- 
action administrator. 

[0017] . The transaction identifier may be a unique 
transaction identifier. 

[0018] According to a second aspect of the invention 
there is provided a system for providing secure transac- 
tions between an originator and a recipient comprising: 
first processing means associated with the originator for 
generating an electronic transaction having a transac- 
tion identifier; second processing means associated 
with the recipient arranged to generate a verification re- 
quest in response to receipt of the transaction for gen- 
erating; third processing means associated with a trans- 
action administrator for receiving the verification request 
from the recipient; andmeans to securely communicate 
information between the first processing means and the 



third processing means to determine validity of the 
transaction based on the transaction identifier. 
[0019] The second processing means may transmit 
the transaction to the third processing means as part of 

s the verification request. 

[0020] The first processing means may generate the 
transaction identifier associated with the transaction or 
in the alternative the third processing means may gen- 
erate the transaction identifier associated with the trans- 

10 action. 

[0021] According to a third aspect of the invention 
there is provided a system administrator for managing 
transactions between an originator and a recipient com- 
prising: means for receiving a verification request from 
is a transaction recipient; and means for securely commu- 
nicating information with a transaction originator to val- 
idate the transaction based on a transaction identifier 
included in the transaction. 

[0022] According to a fourth aspect there is provided 
20 a method for providing a validated electronic transaction 
between an originator, a recipient and a transaction ad- 
ministrator, comprising the steps of: generating an elec- 
tronic transaction including at least a unique transaction 
identifier associated therewith; transmitting the elec- 
ts tronic transaction from the originator to the transaction 
administrator through the recipient; transmitting the 
electronic transaction from the transaction administrator 
to the originator for validation; validating the electronic 
transaction at the originator based on the unique trans- 
30 action identifier; notifying the transaction administrator 
of a validation status of the electronic transaction based 
on the validation; and completing the electronic trans- 
action based on the validation status. 
[0023] According to a fifth aspect there is provided a 
35 method for providing a validated electronic transactions 
between an originator, a recipient and a transaction ad- 
ministrator, comprising the steps of: requesting an elec- 
tronic transaction from the originator to the recipient, the 
electronic transaction including a unique transaction 
40 identifier, an originator identifier and transaction data; 
requesting validation of the originator identifier and the 
transaction data from the transaction administrator; re- 
questing validation of the unique transaction identifier 
and the transaction data from the originator; completing 
45 the electronic transaction if the unique transaction iden- 
tifier, the originator identifier and the translation data are 
validated by both the originator and the transaction ad- 
ministrator. 

[0024] According to a sixth aspect there is provided a 
50 method for providing electronic transactions comprising 
the steps of: transmitting a transaction from an originator 
to a recipient, said request including at least an origina- 
tor identifier; transmitting a first verification request from 
the recipient to a transaction administrator to verify the 
55 originator identifier; verifying the identifier for the origi- 
nator at the transaction administrator; transmitting a 
second verification request from the transaction admin- 
istrator to the originator to determine if the originator 
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generated the transaction ; verifying if the originator gen- 
erated the transaction; and completing the transaction 
in response to answers on the first and the second ver- 
ification requests. 

[0025] According to a seventh aspect there is provid- s 
ed a method for providing electronic transactions com- 
prising the steps of: transmitting a transaction from a 
originator to a recipient, the transaction including an 
originator identifier; associating a unique transaction 
identifier with the transaction; transmitting a first verifi- 10 
cation request including the unique transaction identifier 
from the recipient to a transaction administrator to verify 
the originator identifier; transmitting the unique transac- 
tion identifier from the transaction administrator to the 
originator; comparing the unique transaction identifier to is 
other unique transaction identifiers generated by the 
originator to determine if the originator generated the 
unique transaction identifier; and completing the trans- 
action if the originator generated the unique transaction 
identifier. 2 o 
[0026] According to an eighth aspect there is provided 
a method for providing electronic transactions over a 
computer network between an interconnected origina- 
tor, recipient, and a transaction administrator, compris- 
ing the steps of: generating a first e-mail message from 25 
the originator to the recipient containing a transaction, 
the transaction containing a unique transaction identifi- 
er, an originator identifier and transaction data; gener- 
ating in response to the first e-mail message a second 
e-mail message from the recipient to the transaction ad- 30 
ministrator requesting validation of the originator identi- 
fier, the second e-mail message including the unique 
transaction identifier and the originator identifier; gener- 
ating in response to the second e-mail message a third 
e-mail message from the transaction administrator to 35 
the originator requesting validation of the unique trans- 
action identifier, the third e-mail message including the 
unique transaction identifier; comparing the unique 
transaction number from the third e-mail message to 
other unique transaction numbers generated by the 40 
originator to determine if the originator generated the 
transaction; and completing the transaction based upon 
the results of the comparison. 

[0027] According to a ninth aspect there is provided 
a method for transmitting information between an origi- 45 
nator, a recipient and a transaction administrator, com- 
prising the steps of: associating the information with a 
unique transaction identifier and an originator identifier; 
transmitting an information request from the originator 
to the recipient; requesting validation of the originator 50 
identifier from a transaction administrator; validating the 
originator identifier at the transaction administrator; re- 
questing validation of the unique transaction identifier 
associated with the information from the originator; val- 
idating the unique transaction identifier at the originator; 55 
notifying the transaction administrator of a validation 
status of the information based on the validation; and 
transferring the requested information upon validation 



by the originator and the transaction administrator 
[0028] According to a tenth aspect there is provided 
a system from providing secure electronic transactions 
between an originator, a recipient and a transaction ad- 
ministrator, comprising: first processing means associ- 
ated with the originator for generating a electronic trans- 
action having a unique transaction identifier and an orig- 
inator identifier, associated therewith; second process- 
ing means associated with the recipient responsive 
electronic transaction from the originator for generating 
validation requests on the originator identifier to the 
transaction administrator; 

third processing means associated with the trans- 
action administrator for forwarding the unique transac- 
tion identifier to the originator to determine the validity 
of the electronic transaction and fourth processing 
means for comparing a unique transaction identifier re- 
ceived from the transaction administration to the unique 
transaction identifier generated by the second process- 
ing means to determine the validity of the transaction. 
[0029] According to an eleventh aspect there is pro- 
vided a method for enabling electronic transactions be- 
tween a first party, a second party and a transaction ad- 
ministrator, comprising the steps of: generating a re- 
quest for processing of an electronic transaction; asso- 
ciating a unique transaction identifier with the electronic 
transaction, the unique transaction identifier indicating 
a valid transaction; determining the validity of the elec- 
tronic commerce transaction by comparison of the 
unique transaction identifier with a list of valid unique 
transaction identifiers; and completing the electronic 
commerce transaction based upon the results of the de- 
termination of the validity of the unique transaction iden- 
tifier. 

[0030] According to a twelfth aspeci of the invention 
there is provided a method of validating an electronic 
transaction between an originator and a recipient com- 
prising the steps of: generating an electronic transaction 
at the originator; transmitting the transaction to the re- 
cipient; verifying the transaction; and communicating in- 
formation between the originator and the transaction ad- 
ministrator to validate the transaction. 
[0031] The present invention overcomes the forego- 
ing and other problems with a method and apparatus 
enabling verification and validation of original "electron- 
ic transaction" between one or more originators, recipi- 
ents, and transaction administrators (TA). The originator 
is a party who originates the transaction, for example for 
exchanging information documents or for initiating a 
payment via an electronic check or a payment transac- 
tion for goods and services from the recipient. The orig- 
inator is synonymous with "client", "purchaser", "user", 
"requestor" and "account holder". The recipient is the 
entity receiving for example the information document 
or payment for a provided service such as a utility bill or 
a merchant who provides goods and services. Recipient 
is synonymous with "merchant", "service provider", 
Vendor" and "payee". The transaction administrator 
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(TA) is an entity which authenticates entities and vali- 
dates the content of the transaction by the originator. 
Transaction administrator is synonymous with "Credit 
Card Authority (CAA)', "Government Authority", "Finan- 
cial Network", or "Banking system (BS)". 
[0032] A validated transaction is a transaction in 
which the TA validated the entities, facilitates the trans- 
action and/or validates the contents of the transaction 
by the originator. In a validated electronic transaction, 
either the client, merchant or transaction administrator 
can initiate the transaction. In other transaction, the cli- 
ent may initiate a transaction, for example requesting 
particular items of merchandise or services from a mer- 
chant via the Internet, a dial-up-network, or any suitable 
network. The electronic transaction includes details of 
the transaction such as descriptions of the item(s) that 
the client desires to purchase, credit card or check pay- 
ment information, information on other types of payment 
by means of which the item(s) will be purchased, and a 
transaction identifier that has been generated by the 
originator and is uniquely associated with the particular 
purchase transaction. 

[0033] This information is transmitted to the merchant 
over the network. In response to e.g. a purchase order, 
the merchant generates a payment authorization re- 
quest for transmission to the TA. The payment authori- 
zation request will have attached to it the transaction 
identifier initially provided by the client along with trans- 
action information. Upon receipt of the payment author- 
ization request the TA will validate the client and the 
merchant using the information provided. The TA then 
generates a validation request to the client that includes 
the transaction identifier. This communication between 
the TA and the client may be encrypted using a suitable 
encryption method or a set of virtual keys known only to 
the TA and each individual purchaser. 
[0034] Upon receipt of the validation request, the cli- 
ent decodes, if necessary, the encrypted validation re- 
quest and extracts the transaction identifier therefrom. 
The identifier is compared to a listing of generated trans- 
action identifiers at the client to confirm that the client 
authorized the transaction order with which the transac- 
tion identifier is associated. Confirmation or denial of the 
validation is transmitted back to the TA by the originator. 
This confirmation may be encrypted using a suitable en- 
cryption method, if necessary. To provide additional se- 
curity, a query or group of queries may be included with- 
in the validation requests between the TA and the orig- 
inator. These queries are randomly generated and di- 
rected to information known solely by the originator, 
such as mother's maiden name, social security number, 
driver's license number, birth date, etc. Upon receipt of 
validation or non -validation from the originator, the TA 
confirms or aborts the transaction by notifying the recip- 
ient whether or not the transaction is valid based upon 
the originator's validation response and the accuracy of 
the information contained in the transaction request. If 
the information in the transaction request checks out, 



the item(s) ordered may be delivered to the originator 
by the recipient. The delivery and communication sys- 
tems between the client, merchant and TA preferably 
consists of some type of computer network such as the 
5 Internet, private Intranet or any suitable network. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0035] For a more complete understanding of the 
10 present invention, reference is made to the following de- 
tailed description taken in conjunction with the accom- 
panying drawings wherein: 

FIGURE 1 is a diagram of a commercial transaction 
15 between a client, merchant and credit card author- 
ity; 

FIGURE 2 is a flow diagram describing the transac- 
tion of FIGURE 1 ; 

FIGURE 3 is a diagram of a validated commercial 
20 transaction using the present invention between an 
originator, a recipient and a transaction administra- 
tor; 

FIGURE 4 is a flow diagram describing the transac- 
tion of FIGURE 3; 

25 FIGURE 5 is a diagram of an electronic commerce 
transaction using a credit card according to the 
method of the present invention; . 
FIGURE 6 is a flow diagram describing the transac- 
tion of FIGURE 5; 

30 FIGURE 7 is a diagram of an electronic commerce 
transaction according to an alternative embodiment 
of the method of the present invention; 
FIGURE 8 is a flow diagram describing the transac- 
tion of FIGURE 7; 

35 FIGURE 9 is a diagram of an electronic commerce 
banking transaction to a payee for goods and serv- 
ices according to the method of the present inven- 
tion; 

FIGURE 10 is a flow diagram describing the trans- 

40 action of FIGURE 9; 

FIGURE 11 is an illustration of an e-mail control sys- 
tem architecture enabling electronic commerce 
transactions according to the present invention; 
FIGURE 12 is an illustration of an e-mail record 

45 stored within an e-mail database; 

FIGURE 1 3 is a flow diagram of a "send" mail action 
of an electronic commerce transaction using an e- 
mail delivery system; 

FIGURE 1 4 is a flow diagram of a "receive 0 mail ac- 
50 tion of an electronic commerce transaction using an 
e-mail delivery system; 

FIGURE 15 is an illustration of an electronic trans- 
action between an originator, recipient and transac- 
tion administrator using an e-mail delivery system; 
55 and 

FIGURE 16 is an illustration of an originator and a 
recipient exchanging information documents via an 
e-mail delivery system where the originator, the re- 
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cipient and the information documents are validated 
directly by the transaction administrator. 

DETAILE D DESCRIPTION OF THE INVENTION 

[0036] Referring now to drawings and more particu- 
larly to FIGURES 3 and 4, there is illustrated a system 
and method for improved electronic transactions. An 
originator 50 initiates a transaction at step 65 using proc- 
essor 70. The transaction may comprise a purchase, 
payment or request for an information document from 
recipient 55. The transaction request includes a unique 
transaction identifier (UTID) associated with the specific 
transaction request and originator identity (OID) to iden- 
tify the originator 50 to a transaction administrator 60. 
The originator identity ma y comprise a credit c ard 

number, account number, etc. ■■■■■ * 

[0037] The processor 70 referenced above is any suit- 
able processor capable of handling transaction process- 
ing systems such as a personal computer (e.g. PC, Mac, 
Hand held PC), a point of sales (POS) device, a POS 
device with a Smart Card, a work station, a server or 
any other suitable hardware/software combination. The 
merchant 55 and TA 60 also include suitable processors 
at their facilities to run the electronic commerce trans- 
action. 

[0038] Recipient 55 first reviews the transaction re- 
quest using a processor 75 and generates a request for 
authentication of the originator 50 using the OID, UTID 
and the information content of the transaction request 
such as an amount or document name at step 80 to the 
transaction administrator. The transaction administrator 
60 first validates the identity of recipient 55 and then the 
OID at step 85. If the OID is invalid, the transaction ad- 
ministrator 60 notifies the recipient 55 of the invalidity 
and the transaction is denied. If the OID is valid, the 
transaction administrator 60 determines the originator 
associated with the OID, transmits the transaction re- 
quest and associated data to the originator 50 and re- 
quests that the originator validate the transaction re- 
quest containing the UTID at step 90. The transaction 
administrator 60 may also validate transaction amounts 
and credit limits at this time or upon receiving a response 
for the originator 50. 

[0039] The originator 50 validates the transaction by 
comparing at step 95 the UTID with a list 100 generated 
by the processor 70 of the originator listing the UTID as- 
sociated with each transaction generated by the origi- 
nator and notifying the transaction administrator 60 of 
the results. The list 100 also includes the details of the 
transaction (amount; parties, etc.) associated with the 
UTID which must also be validated by the originator 50. 
The transaction is granted or rejected by the transaction 
administrator 60 based on the comparison results at 
step 1 05. If the originator 50 does not validate the trans- ss 
action at step 95, the transaction administrator 60 re- 
jects the transaction at step 110 which invalidates the 
transaction. The originator is notified at step 115 of the 
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invalidation of the transaction. Upon receipt of the trans- 
action validation status from the originator 50, the trans- 
action administrator 60 validates the originator 50 and 
the transaction request at step 120, and notifies the re- 
cipient 55. The originator 50 and recipient 55 then com- 
plete the transaction at step 125. 
[0040] Validation of the originator 50, recipient 55 and 
transaction administrator 60 may be validated by the 
use of digital signatures transmitted along with the var- 
ious transmissions between parties in a known manner. 
Additionally, the identity of the originator 50 may be val- 
idated by requiring the originator to answer a series of 
questions that only the originator would know, such as 
mother's maiden name, social security number, etc. This 
configuration may be used to carry out a variety of dif- 
ferent types of electronic commerce transactions. For 
example, if the originator 50 requests a document, the 
recipients 55 can send the document to the originator 
50. An originator may also pay bills or purchase mer- 
chandise. There are several variations of this embodi- 
ment in which a transaction administrator 60, originator 
50 and recipient 55, can initiate transactions and sever- 
al, but not all, of these variations are illustrated in the 
following examples. 

[0041] For purposes of discussion, entities and com- 
ponents related to those disclosed in the embodiment 
described in FIGURES 3 and 4 will be given similar ref- 
erence numbers in the remainder of the FIGURES. Re- 
ferring now to FIGURES 5 and 6, these are illustrated 
diagrams for a particular embodiment of the invention 
for a credit card transaction between a client 50, mer- 
chant 55 and credit authority (CA) 60. A client 50 places 
a purchase order to the merchant 55 at step 150. The 
purchase order is generated by an electronic transac- 
tion processor 70 associated with ihe client 50. The pur- 
chase order includes a UTID 60 generated by the proc- 
essor 70 that is uniquely associated with the transaction, 
an amount and a credit card number. Once the purchase 
order is received, the merchant 55 transmits at step 155 
a request for payment authorization to the CA 60 over 
the Internet or a private network. Along with the confir- 
mation request, the merchant 55 transmits the UTID, 
credit card number and data concerning the purchase 
order to the CA 60. 

[0042] Upon receipt of the payment authorization re- 
quest from the merchant 55, a CA processor 61 deter- 
mines if the purchase order is authorized at step 1 00 by 
attending to the validity of the credit card number, mer- 
chant, amount of purchase, etc., and determine the cli- 
ent identity. The CA 60 transmits at step 165, the pur- 
chase order and the associated UTID 60 and purchase 
order data to the client processor 70. The UTID 60 and 
purchase order data are processed at the client 50 to 
determine if they are valid. The transmission from the 
CA 60 to the client 50 may be encoded using some type 
of virtual encryption key or any suitable encryption tech- 
nology. The client processor 70 decodes the transmis- 
sion (if encrypted) using knowledge of the virtual encryp- 
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tion key method between the client 50 and the CA 60 
and compares the received unique transaction identifier 
to a unique transaction identifier list 100 of identifiers 
transmitted from the client at step 170 to determine 
whether to validate the transaction. The results of the 
validation is then forwarded to the CA 60. If the UTID 60 
matches an entry within the client list 100 and the pur- 
chase order data checks out with what the client 50 ex- 
pects, the requested transaction is identified as valid. If 
no match for the UTID is found or if the purchase order 
data is incorrect the requested transaction is identified 
as invalid or fraudulent. 

[0043] As an additional protection, the CA 60 may 
query the client processor 70 for various items of infor- 
mation that only the client 50 would know, such as moth- 
er's maiden name, driver's license number, etc. This 
query may be constantly changed, such that an unau- 
thorized user would not be able to predict what informa- 
tion the CA 60 might ask for. Additionally, digital signa- 
tures may be used to help identify parties. 
[0044] The CA 60 responds at step 180, with an au- 
thorization for the transaction if the client 50 transaction 
and credit limit have been approved by the CA proces- 
sor 61 and if there is a confirmation by client 1 0 of trans- 
action validity. If the transaction is not validated by either 
the CA 60 or client 50, the CA transmits a rejection of 
the requested transaction to the merchant at step 185, 
and the client is notified by the merchant of the rejection 
at step 190. Upon confirmation of the purchase order, 
the merchandise may be delivered to the client 50 and 
a credit card transaction can be completed between cli- 
ent 50 and merchant 55 at step 195. Communication 
between the client 50 and the CA 60 guarantees that an 
unauthorized purchase order is not issued by an unau- 
thorized client or merchant 55 and that a merchant does 
not change the amount on the purchase order issued by 
the client. Furthermore, the delivery address may be 
confirmed by the client 50 prior to receipt of the goods. 
The use of the UTID in all communications between the 
client 50, merchant 55 and the CA 60, and the verifica- 
tion and validation of the purchase order by the client 
reduces fraudulent transactions. The system provides 
a mechanism for consumers to ensure the validity of 
transactions and thus enhances the overall security of 
electronic commerce. The UTID ties together all three 
delivery systems. The virtual keys used in communica- 
tions between client 50 and the CA 60 not only prohibits 
unauthorized clients from performing a transaction but 
verifies that the current transaction has been initiated 
from the true client. 

[0045] In an alternative embodiment parties other 
than the originator 50 may create the UTID, for example 
the TA 60. A system and method for this type of trans- 
action are illustrated in FIGURES 7 and 8. Initially, client 
50 generates at processor 70, a credit authorization re- 
quest including an originator identifier and relevant in- 
formation to credit authority (CA) 60 at step 200. The 
C A 60 processes the credit request to determine the va- 



lidity of the client 50 requesting credit based on the orig- 
inator identifier and the associated amount at step 205. 
The CA 60 then sends the credit transaction information 
along with an associated UTID or a rejection of author- 

5 ization back to client 50 at step 210. Upon receipt of 
credit approval and the UTID, the client 50, transmits a 
purchase request with the provided UTID to the mer- 
chant 55 at step 215. The merchant 55 sends a request 
for transaction validation of the UTID to the CA 60 at 

10 step 218. The CA 60 compares the transaction informa- 
tion, including UTID, with the original credit transaction 
and UTID in a list 100 of credit transactions and asso- 
ciated UTIDs generated by the CA and responds to the 
merchant 60 regarding the validity of the transaction at 

is step 220. The comparison at the CA 60 uses a proces- 
sor 61. The list 100 comprises credit transactions and 
associated UTIDs created by the processor 61. The 
merchant 55 accepts or rejects the transaction at step 
225 based on the comparison performed at step 220 by 

20 the CA 60. If the merchant 55 accepts the transaction 
at step 225, the order is provided to the client 50 at step 
230. If the merchant 55 rejects the transaction at step 
225, it notifies the client 50 of the rejection at step 235. 
Each transaction is tracked by a corresponding UTID, 

25 and is verified by the CA 60 with reference to the origi- 
nator 50 and the issuance of the UTID. 
[0046] FIGURES 9 and 10 illustrate another example 
of the proposed method and apparatus to enable vali- 
dated banking transactions, bet ween an account holder 

30 or client 50 and any third party payee 55. This time a 
validation is performed between the client 50 and a cli- 
ent bank 250 in the banking system 60 to guarantee that 
a valid client 50 requested a payment transaction. Ini- 
tially, a client 50 initiates a payment transaction to the 

35 payee 55 at step 255 in the form of, for example, an elec- 
tronic check. The electronic check includes a UTID and 
associated electronic check information such as 
amount, account number, etc. In response to the elec- 
tronic check, the payee 55 requests payment of the elec- 

40 tronic check from the banking system 60 or deposits the 
electronic check into payee bank 260 at step 265. Upon 
receipt of the request or deposit, the payee bank 260 in 
conjunction with the client bank 250 in the banking sys- 
tem 60 determines the validity of the electronic check 

45 including bank number, fund availability, account 
number, etc. at step 270 and identifies the associated 
client or account holder 50 that initiated the transaction. 
[0047] The banking system 60 then sends the elec- 
tronic check along with the associated UTID to the client 

50 50 for validation at step 275. The client 50 compares the 
information on the transaction with the original payment 
transactions and associated UTIDs and other relevant 
payment information at step 280 from a list 100. The list 
1 00 will include all original electronic check transactions 

55 and the related information and UTIDs generated by the 
client 50. The client 50 then notifies the client bank 250 
in the banking system 60 with a verdict on the validity of 
the transaction. Based on the validity determination pro- 



8NSDOC1D:<EP 1026644A1 



13 



EP 1 026 644 A1 



14 



vided by the client 50 and the client bank's 250 validity 
checks, the payee bank 260/banking system 60 grants 
or rejects the payment transaction at step 285. If the 
banking system 60 approves the payment transaction 
request at step 91 , the payment transaction is then com- s 
pleted at step 290 by transferring funds to the proper 
accounts. If the transaction is rejected at step 93, the 
banking system 60 notifies the client 50 and the payee 
55 of the rejection of the electronic check payment trans- 
action at step 295. 10 
[0048] Generally, the payee 55 deposits the electronic 
check in his/her account at payee bank 260 within the 
banking system 60. The payee bank 260 confirms the 
client's identity, account number and relevant informa- 
tion. The payee bank 260 next sends the electronic is 
check for the payment to the client bank 250 of the client 
50 via check clearing house (CCH) 299. Checkclearing 
house 299 debits client's bank account and credits pay- 
ee's bank account subject to client's bank validation of 
checks received from the payee 55. When the client's 20 
bank 250 receives an electronic check from the Check 
Clearing House 299 it validates the check (authenti- 
cates the check with the client 50 signature and availa- 
ble funds in the client's account). If the client's bank 250 
does not validate the check, it rejects the check for the 25 
payment, and the check clearing house 299 reverses 
the transaction and notifies the payee bank 260. The 
payee's bank 260 then notifies the payee 55 that the 
check is "bounced" or returned back for insufficient 
amount or whatever else is the cause. All these process- 30 
ing steps may be performed in electronic transactions. 
[0049] The communications between the originator 
50 and TA 60 or between the recipient 55 and the TA 60 
can be established with any traceable delivery system, 
such as a point-to-point tunneling protocol (PPTP) 35 
which is equivalent to a telephone virtual circuit. How- 
ever, an e-mail system also provides a traceable deliv- 
ery system in an alternative embodiment an e-mail de- 
livery system may be used not only to exchange infor- 
mation, but to process complex transactions and safely 40 
share information between multiple entities. Referring 
now to FIGURE 1 1 , there is illustrated an e-mail control 
system (ECS) 300 enabling electronic commerce trans- 
actions on the Internet between an originator 50, recip- 
ient 55, and transaction administrator 60. The system 4S 
guarantees the validity of the electronic commerce 
transaction by validating that the client owning a pre- 
sented credit card number, unique transaction identifier, 
transaction amount, etc., has initiated the transaction. 
There exists a traceable delivery system on computer so 
networks such as the Internet, Intranet or private net- 
work, namely e-mail. An existing e-mail system may be 
extended so that an originator 50 can openly use pay- 
ment numbers, such as credit card numbers and ac- 
count numbers, over the Internet. The terms E-mail and 55 
e-mail are synonymous. In this example an ECS 300 
interfaces with an e-mail delivery system 305 using the 
SMTP protocol to send mail and the POP3 protocol to 



receive mail. The ECS 300 enforces the new behavior 
of the e-mail delivery system 305 to perform transac- 
tions between the originator 50, the recipient 55 and the 
transaction administrator 60. The ECS 300 may be im- 
plemented in single or multiple processors wherein sep- 
arate processors control transaction e-mails and normal 
e-mails. 

[0050] The ECS 300 uses the e-mail delivery system 
305 (or suitable applications or functions) in conjunction 
with a mailbox database 315 to create, reply to or view 
e-mail messages. The ECS 300 sends and receives e- 
mail messages to/from the e-mail delivery system 305 
using send mail 310 and receive mail 320 actions/func- 
tions of the e-mail system. The ECS 300 includes infor- 
mation such as UTID, OID and transaction data within 
a transaction e-mail and enables extraction of this infor- 
mation at a receiving part for further transaction 
processing such as validation. The mailbox database 
315 includes a plurality of e-mail records 330, each hav- 
ing a unique transaction identifier 331 (FIGURE 12) as- 
sociated therewith that has been generated by the e- 
mail control system 300. 

[0051] A format of an e-mail record 330 is more fully 
described in FIGURE 12 wherein there is shown an e- 
mail record 330 including the unique transaction identi- 
fier or message ID 331; a mail type identification 335 
indicating whether the record is to be transmitted, was 
just received, has already been transmitted, or comprise 
a transaction e-mail; the recipient's address 340; the 
subject matter of the e-mail 345; and the contents of the 
e-mail 348. For simplicity, the mail type identification 335 
identifies the state of the e-mail record as it relates to 
the state of the e-mail delivery system 305. For example, 
when a user creates an e-mail record, the ECS 300 de- 
posits this e-mail record into the mailbox database 315 
with mail "type" equal to 1 indicating that the e-mail 
record is ready to be delivered to the recipients. The re- 
cipient address 340, subject matter 345 and contents 
348 provide routing and content information to the e- 
mail delivery system 305. 

[0052] When e-mail messages are utilized to provide 
electronic commerce transactions various parts of the 
e-mail record 330 will have a specific format to enable 
identification of an electronic commerce transaction and 
extraction of relevant data from the e-mail record. For 
example, when an electronic check is used, the subject 
345 of the e-mail message may be formatted to read in 
one of the following manners to enable recognition by 
the e-mail control system 300: 

1 "CheckNumber" - identifies a transaction e-mail 
requesting an electronic commerce transaction by 
the originator to the recipient. 

2. "Val:#CheckNumber" - identifies validation re- 
quests from the transaction administrator to the 
originator. 
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3. n Re:#CheckNumber a - identifies a reply from the 
transaction administrator to the recipient. . 

4. 0 ACK;#CheckNumber o - identifies positive vali- 
dation from the originator. 

5. fl NACK;#CheckNumber[code] B - identifies a neg- 
ative validation and a code indicating the reason for 
the negative validation from the originator. 

[0053] In the case of an electronic check transaction, 
the mail contents 348 of the e-mail may comprise a 
number of items, depending on who the e-mail is from, 
and the data required to be extracted by the e-mail con- 
trol system 300 of the receiving party. A transaction re- 
quest from the originator 50 may include an account 
number, amount of the transaction, account reference, 
transaction reference, and originator's personal infor- 
mation. A response from a recipient 55 may include ac- 
count number information, account references, transac- 
tion references, and recipient's personal information. An 
e-mail message from the transaction administrator 60 
may contain query information for the originator to ob- 
tain validation. 

[0054] There may be several variations of this mail 
content 348 information. For example, a party may use 
the message I.D. field of the e-mail services delivery 
system 305 to create a unique transaction identifier. This 
message I.D. field may act as a UTID and identify a 
transaction type. For example, a message I.D. type of 
the form #[TYPE][UNIQUE SEQUENCE NUMBER] 
[ORIGINATOR E-MAIL ADDRESS] identifies the type of 
transaction, a unique sequence number generated by 
the e-mail control system 300 and the originator's e-mail 
address. In the case of a check transaction, the UTID 
would appear as follows: 

#c0000001originator@joe.doe 

#c0000002or i g inatorat @ joe . d oe . 
This information would notify the ECS 300 how a trans- 
action was to be processed. 

[0055] The subject field may contain a transaction da- 
ta identifier, such as a purchase order number of the 
originator 50, and an invoice number of the recipient 55 
such that the transaction can be related to a prior trans- 
action or another message processing system process- 
ing the transaction data. For example, upon successful 
transfer of fund deposits from a transaction administra- 
tor, the recipient can use an invoice number to credit the 
originator's account. 

[0056] As noted above, the ECS 300 sends and re- 
ceives e-mail via send 310 and receive 320 mail actions 
defined within the e-mail system. When a user selects 
an action from the user interface (not shown), preferably 
by pointing and clicking on the icon identifying the ac- 
tion, the ECS 300 executes the action. A send mail ac- 
tion 310 sends all e-mail marked "Type 1" to the e-mail 
delivery system 305 via an SMTP interface and a re- 
ceive mail action 320 receives all new mail.from the e- 



mail delivery system 305 using a POP3 or similar inter- 
face. When the ECS 300 receives a new e-mail mes- 
sage, it loads the e-mail message into the mailbox da- 
tabase 31 5 as an e-mail record 330 and notifies the cli- 
5 ent 50. If the client 50 has any new mail and selects a 
View new mair action, the ECS 300 starts the "display 
mail" using a graphical user interface to display the new 
mail. 

[0057] FIGURES 13 and 14 describe the Send 310 

io and Receive 320 3-mail actions, respectively, of the e- 
mail control system 300 shown in FIGURE 1 1 . The send 
mail action 31 0 first checks if an e-mail record 330 con- 
tains a transaction at inquiry step 350. If a transaction 
is indicated, a series of tasks are performed at step 355. 

15 Initially a UTID is created. A delivery timer is initiated 
and the e-mail is marked for delivery. The e-mail record 
330 is then loaded into the mail box database 31 5. The 
e-mail record is then ready for delivery to the recipient 
at step 360. Inquiry step 365 determines whether or not 

20 the delivery was a success. If so, the e-mail record is 
marked as delivered to the mail box database 315 at 
step 370 and the procedure is completed. Otherwise, 
no indication of delivery is provided. 
[0058] The receive e-mail action 320 gets new e-mail 

25 from the e-mail delivery system 305 at step 375 and de- 
termines if the e-mail comprises transaction mail at step 
380. If the e-mail comprises transaction mail, then the 
receive mail action 320 creates a proper reply with an 
attached UTID at step 385 and places the reply into the 

30 mail box database 31 5 for delivery at step 390. If the e- 
mail does not comprise transaction mail, the e-mail is 
placed directly in the mail box database 31 5 at step 395. 
These two actions allow the e-mail control system to 
properly process e-mail transactions to enable electron- 

35 \c commerce. 

[0059] Referring now also to FIGURE 15, there is il- 
lustrated an application of, the present invention where- 
by an electronic commerce transaction may occur be- 
tween a client 50, a merchant 55 and a CA 60 utilizing 

40 an e-mail delivery system 305 to enable confirmation of 
the validity of the transaction. As discussed previously, 
the client 50 generates a purchase order which is for- 
matted and transmitted to the merchant 55 via an e-mail 
message at 400. The ECS 300 causes the unique trans- 

45 action identifier to be generated and attached to the e- 
mail message record 330 from the client 50 and formats 
transaction data within the message. The e-mail record 
330 may be of the form of the records discussed previ- 
ously. The merchant 55 receives and processes this e- 

50 mail message to extract relevant data and generates an- 
other e-mail message at 405 to the CA 60 requesting 
verification and authorization of the charge amount and 
the credit card number provided by the client 50. This 
e-mail message is also formatted by the ECS 300 to in- 

55 elude the UTID and relevant transaction data initially 
transmitted by the client 50. 

[0060] The C A 60 formats and generates yet another 
e-mail message which may be encoded using some 
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type of virtual key encryption (or other type of encryp- 
tion) for transmission to the client 50 at 410. Included 
within the e-mail message by the ECS 300 are the 
unique transaction identifier; purchase order data such 
as item, amount and delivery address; and optionally 
randomly generated questions on which only the client 
50 has knowledge, such as birth date, mother's maiden 
name, social security number, etc. The client 50 utilizing 
its knowledge of the virtual key decrypts the e-mail mes- 
sage, extracts the relevant transaction data and com- 
pares the UTID provided in the e-mail message to the 
unique transaction identifier list 100 at the client 50 to 
determine whether or not the requested transaction has 
been initiated by the client. 

[0061] If a match on the list 1 00 is found, the purchase 
order data is checked against the transaction data as- 
sociated with the match. If the data matches, the client 
50 generates an e-mail message to the CCA at 415 in- 
dicating that the requested transaction originated with 
the client (transaction valid) and provides responses to 
the random questions generated by the CA 60. This e- 
mail message could be encrypted if the client 50 so de- 
sires. 

[0062] The CA 60, upon confirmation of the answer to 
the random questions and verification of the transaction 
by the client, transmits an e-mail message to the mer- 
chant 55 at 420 enabling delivery of the requested mer- 
chandise or services to the client at 425. If the transac- 
tion is not validated by either the client 50 or the credit 
authority 60 due to an improper UTID, improper query 
response or lack of authorization for the claimed credit 
limit amounts by the credit card authority, completion of 
the transaction is denied at 420 in an e-mail message. 
[0063] Each of the e-mail messages transmitted by 
the e-mail delivery system 305 are responsive toqueries 
to the e-mail control system 300 generated by a trans- 
action request. The transaction request causes the e- 
mail control system 300 to generate the e-mail record 
330 having the unique global transaction identifier or 
message identifier 331 , a mail type identification 335 in- 
dicating a transaction, and the mail content 348, includ- 
ing all information necessary to perform the validation 
and authorization procedures at the credit authorities or 
transaction administrator and the transaction originating 
party. 

[0064] Referring now to FIGURE 1 6, there is illustrat- 
ed an exchange of information between an originator 50 
and a recipient 55 using an e-mail delivery system 305. 
Information is synonymous with document, software, 
classified data, transaction data or a database query 
and responses. The invention provides a method to se- 
curely exchange and process information between orig- 
inator 50 and recipient 55, where an originator and re- 
cipient can be client or server on the Internet/Intranet or 
private network. Please note that currently, it is not pos- 
sible to perform transaction processing between two cli- 
ents on the Internet or Intranet. The present invention 
not only provides a method to perform transaction 



processing between two clients but also creates an au- 
tomated secure information exchange firewall. While 
the following is described with respect to an e-mail de- 
livery system it should be realized that any type of de- 
5 livery system would be useful. The originator 50 sends 
a document including a UTID and originator identifier 
(OID) to recipient 55 within an e-mail message at 430. 
Upon receipt of the e-mail message, the recipient 55 for- 
wards another e-mail message to the transaction ad- 
io ministrator (TA) 60 at 435. The e-mail message includes 
the OID, UTID and document name. The TA 60 authen- 
ticates the OID of originator so a message can be trans- 
mitted to the originator. If OID does not authorize, the 
TA 60 sends a negative response to recipient 55 at 450. 
15 Otherwise, the TA 60 requests originator 50 to validate 
the transaction via another e-mail message at 440. The 
e-mail message includes the UTID. 
[0065] The originator 50 validates transactions by 
comparing UTID with a list 100, including UTIDs gener- 
20 ated by the originator along with associated information. 
The originator 50 sends a negative acknowledgment 
due to failure to match a UTID or associated information 
if the transaction is invalid or a positive acknowledgment 
if the transaction is valid and the UTID and associated 
25 information matches at 445. The TA 60 upon receipt of 
a positive or negative validation of the transaction with 
the associated UTID notifies the recipient of a positive 
status at 450. 

[0066] The originator and the recipient then com- 
30 pietes the information transaction at 455. For example, 
if recipient receives a positive acknowledgment for 
transaction, it accepts the information. Since the OID is 
authenticated by the TA 60, the recipient 55 is guaran- 
teed that the information is received from the desired 
35 originator. In this example, since the originator 50 has 
validated the transaction and information, the originator 
is guaranteed that recipient 55 has received the infor- 
mation. The transaction administrator 60 may be any 

entity, such as a Government authority, U S Post Office 
40 etc. 

[0067] Following is an example, according to Figure 
16, of a client to client information exchange where the 
information comprises transaction data processing. In 
this example, an originator 50 sends an e-mail contain- 
45 ing transaction data including SQL statements asking 
for database records from the recipient 55. Upon receiv- 
ing an e-mail from the originator 50 recipient 55 sends 
an e-mail containing relevant data to the TA 60 to vali- 
date the transaction. The TA 60 validates the recipient 
50 55 and originator 50. The TA 60 then sends a validation 
request via e-mail to the originator 50. The originator 50 
validates the transaction by comparing UTID and trans- 
action contents with the list 75 of transactions and re- 
sponds to, TA 60 regarding the validity of the transac- 
ts tion. TA 60 validates the transaction based on the re- 
sponse from the originator and notifies recipient 55 re- 
garding the validity of the transaction. 
[0068] If the transaction is valid, recipient processes 
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the transaction data request using processor 75 (or an- 
other associated processor) and formats the data into 
an e-mail or sends the transaction data request to an- 
other processor (not shown) which processes the re- 
quest and returns the transaction data into an e-mail for s 
transmission to the originator 50. Requested informa- 
tion could be formatted into an ASCII document or an 
ASCII title with suitable delineation for data separation 
or into an Internet browser HTML document. When the 
originator 50 receives transaction data from the recipi- io 
ent 55, it then displays or processes the data. 
[0069] Although preferred embodiments of the meth- 
od and apparatus of the present invention have been 
illustrated in the accompanying Drawings and are de- 
scribed in the foregoing Detailed Description, it is under- is 
stood that the invention is not limited to the embodi- 
ments disclosed, but is capable of numerous rearrange- 
ments, modifications, and substitutions without depart- 
ing from the spirit of the invention as set forth and de- 
fined by the following claims. 20 



Claims 




644 A1 20 

7. A method as claimed in any preceding claim com- 
prising communicating information between the 
originator and the transaction administrator after 
the transaction has been transmitted. 

8. A method as claimed in claim 7 wherein commu- 
nicating information comprises transmitting a re- 
quest for verification of the transaction from the 
transaction administrator to the originator. 

9. A method as claimed in claim 8 wherein commu- 
nicating information further comprising transmitting 
a verification of the original transaction transmis- 
sion from originator to transaction administrator. 

1 0. A method as claimed in any of claims 3 to 9 com- 
prising generating the transaction identifier at the 
originator. 

1 1 . A method as claimed in claim 1 0 including trans- 
mitting the transaction identifier from the transac- 
tion administrator to the originator as part of the ver- 
ifying step. 



1. A method of validating an electronic transaction 25 
between an originator and a recipient comprising 

t the steps of: 

< generating an electronic transaction, including 

a transaction identifier, at the originator; 30 

y transmitting the transaction to the recipient;and 

~ communicating information between the origi- 

nator and the transaction administrator to vali- 

3 date the transaction based on the transaction 

identifier. 35 

2. A method as claimed in claim 1 including verifying 
the transaction at a transaction administrator; 

3. A method as claimed in claim 2 including trans- 40 
mitting the transaction from the recipient to the 
transaction administrator as part of the verifying 
step. 

4. A method as claimed in claim 3 wherein the ver- 45 
ifying step includes transmitting the transaction 
identifier from the recipient to the transaction ad- 
ministrator. 

5. A method as claimed in claim 3 or 4 wherein the so 
verifying step includes authenticating the transac- 
tion identifier received by the recipient. 

6. A method as claimed in claims 4 or 5 wherein the 
verifying step includes authenticating the transac- 55 
tion identifier received by the transaction adminis- 
trator. 



12. A method as claimed in claim 11 including au- 
thenticating the transaction identifier at the origina- 
tor. 

13. A method as claimed in any of claims 2 to 12 
including transmitting the transaction from the 
transaction administrator to the originator as part of 
the verifying step. 

14. A method as claimed in claims 1 to 6 comprising 
communicating information between the originator 
and the transaction administrator before the trans- 
action has been transmitted. 

15. A method as claimed in claim comprising gen- 
erating the transaction identifier at the transaction 
administrator and transmitting the transaction iden- 
tifier to the originator for inclusion in the transaction. 

16. A method as claimed in claim 15 including au- 
thenticating the transaction identifier at the transac- 
tion administrator. 

17. A method as claimed in claims 3 to 16 where 
the transaction identifier is a unique transaction 
identifier. 

18. A method as claimed in any of claims 2 to 17 
including generating an originator identification and 
including the originator identification in the transac- 
tion. 

19. A method as claimed in claim 18 including au- 
thenticating the originator identifier received by the 
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recipient. 

20. A method as claimed in claim 1 9 including au- 
thenticating the originator identifier at the transac- 
tion administrator. 5 

21. A method as claimed in any of claims 2 to 20 
including generating a recipient identifier and au- 
thenticating the recipient identifier at the transaction 
administrator. 10 

22. A method as claimed in any of claims 2 to 21 
including transaction data in the transaction. 

23. A method as claimed in claim 22 including au- is 
thenticating the transaction data received by the re- 
cipient. 

24. A method as claimed in claim 24, in so far as 
dependent on claim 7, including authenticating the 20 
transaction data at the originator. 

25. A method as claimed in claim 24, in so far as 
dependent on claim 12, wherein transaction data is 
associated with a transaction identifier at the origi- 25 
nator, and both the transaction data and the trans- 
action identifier are included in the transaction. 

26. A method as claimed in claim 25 comprising 
comparing the transaction data and the transaction 30 
identifier received from the transaction administra- 
tor with a list of all transaction identifiers and asso- 
ciated transaction data held at the originator. 

27. A method as claimed in any preceding claim 35 
wherein the transaction is transmitted via"e-mail 
messages over a computer network. 

28. A method as claimed in any preceding claim in 
which the communication between the originator 40 
and the transaction administrator takes the form of 
randomly generated questions of which only the 
originator has knowledge. 

30. A method as claimed in any preceding claim in- 45 
eluding encrypting the communication between the 
originator and the identifier. 

31. A method as claimed in any preceding claim 
comprising completing the transaction in response 50 
to a positive validation of the transaction by the 
transaction administrator. 

32. A method as claimed in claim 30 including, in 

the completing step, transmitting a positive valida- 55 
Won indicator to the recipient and subsequently 
completing the transaction between the originator 
and the recipient. 



33. A method as claimed in claims 29 or 30, in so 
far as dependent on claims 3, 15 and 22, including 
completing the transaction if the transaction identi- 
fier, the originator identifier and the transaction data 
are verified by the transaction administrator. 

34. A system for providing secure transactions be- 
tween an originator and a recipient comprising: 

first processing means associated with the orig- 
inator for generating an electronic transaction 
having a transaction identifier; 
second processing means associated with the 
recipient arranged to generate a verification re- 
quest in response to receipt of the transaction 
for generating; 

third processing means associated with a 
transaction administrator for receiving the ver- 
ification request from the recipient; and 
means to securely communicate information 
between the first processing means and the 
third processing means to determine validity of 
the transaction based on the transaction iden- 
tifier. 

35. A system as claimed in claim 34 wherein the 
second processing means transmits the transaction 
to the third processing means as part of the verifi- 
cation request. 

36. A system as claimed in claim 34 or 35 wherein 
the first processing means generates the transac- 
tion identifier associated with the transaction. 

37. A system as claimed in claim 34 or 35 wherein 
the third processing means generates the transac- 
tion identifier associated with the transaction. 

38. A system as claimed in any of claims 34 to 37 
including a delivery system interconnecting the first, 
second and third processing means. 

39. A system as claimed in claim 38 wherein the 
delivery system is a computer network. 

40. A system as claimed in claim 39 where the com- 
puter network is the Internet. 

41. A system as claimed in any of claims 34 to 39 
wherein the transaction and/or the verification re- 
quest and/or the information is transmitted by an e- 
mail system. 

42. A system as claimed in any of claims 34 to 41 
wherein the transaction and/or the verification re- 
quest and/or the information are encrypted. 

43. A system as claimed in any of claims 34 to 41 
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wherein the third processing means generates ran- 
dom questions, of which only the originator has 
knowledge. 

44. A systems as claimed in any of claims 41 to 43 5 
wherein means for automatically removing the 
transaction identifier is provided in at least one proc- 
essor. 

45. A system as claimed in any of claims 34 to 44 to 
wherein means for comparing the transaction iden- .- 
trfier inserted into the transaction and the transac- 
tion identifier as received by the transaction admin- 
strator are provided. 

15 

46. A system as claimed in claim 45 wherein the 
comparing means is incorporated within at least 
one of the processors and performs the comparison 
automatically. 

20 

47. A system as claimed in any of claims 34 to 46 
wherein the third processing means authenticates 
the originator from an originator identifier associat- 
ed with the transaction. 

25 

48. A system as claimed in any of claims 34 to 47 
wherein the third processing means authenticates 
the recipient from a recipient identifier associated 
with the verification request. 

30 

49. A system as claimed in any of claims 34 to 48 
wherein the third processing means verifies the 
transaction by using transaction data associated 
with the transaction. 

35 

50. A system administrator for managing transac- 
tions between an originator and a recipient compris- 
ing: 

means for receiving a verification request from 40 
a transaction recipient; and 
means for securely communicating information 
with a transaction originator to validate the 
transaction based upon a transaction identifier 
included in the transaction. 45 



51. A method of validating an electronic tranasction 
between an originator and a recipient comprising 
the steps of: 

so 

generating an electronic transaction, including 
a transaction identifier, at the originator; 
transmitting the transaction to the recipient; 
verifying the transaction; and 
communicating information between the origi- 55 
nator and the transaction administrator to vali- 
date the transaction. 
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